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This paper introduces the major components 
of, and standards associated with, the Web 
services architecture. The different roles 
associated with the Web services architecture 
and the programming stack for Web services 
are described. The architectural elements of 
Web services are then related to a real-world 
business scenario in order to illustrate how 
the Web services approach helps solve real 
business problems. 


Web services technology is changing the Internet, 
augmenting the eyeball web with capabilities to pro¬ 
duce the transactional web. The eyeball web is dom¬ 
inated by program-to-user business-to-consumer 
(B2C) interactions. The transactional web will be 
dominated by program-to-program business-to-busi- 
ness (B2B) interactions. This transformation is be¬ 
ing fueled by the program-to-program communica¬ 
tion model of Web services built on existing and 
emerging standards such as HyperText Transfer Pro¬ 
tocol (http), Extensible Markup Language (xml), 
Simple Object Access Protocol (soap), Web Services 
Description Language (wsdl), and the Universal 
Description, Discovery, and Integration (uddi) proj¬ 
ect. 

Web services technologies provide a language-neu¬ 
tral, environment-neutral programming model that 
accelerates application integration inside and out¬ 
side the enterprise. Application integration through 
Web services yields flexible loosely coupled business 
systems. Because Web services are easily applied as 
a wrappering technology around existing applications 
and information technology assets, new solutions can 


be deployed quickly and recomposed to address new 
opportunities. As adoption of Web services accel¬ 
erates, the pool of services will grow, fostering de¬ 
velopment of more dynamic models of just-in-time 
application and business integration over the Inter¬ 
net. 

This paper presents a business scenario showing how 
Web services standards are used to solve problems 
in a business situation. Preceding this scenario is a 
brief overview of the major Web services concepts 
and standards. 

Web services overview 

A Web service is an interface that describes a col¬ 
lection of operations that are network-accessible 
through standardized XML messaging. A Web ser¬ 
vice performs a specific task or a set of tasks. A Web 
service is described using a standard, formal XML no¬ 
tation, called its service description , that provides all 
of the details necessary to interact with the service, 
including message formats (that detail the opera¬ 
tions), transport protocols, and location. Web ser¬ 
vice descriptions are expressed in WSDL. 

This paper describes Web services in terms of a ser¬ 
vice-oriented architecture. As depicted in Figure 1, 
this architecture sets forth three roles and three op¬ 
erations. The three roles are the service provider, 
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the service requester, and the service registry. The 
objects acted upon are the service and the service 
description, and the operations performed by the ac¬ 
tors on these objects are publish, find, and bind. 

A service provider creates a Web service and its ser¬ 
vice definition and then publishes the service with 
a service registry based on a standard called the 
Universal Description, Discovery, and Integration 
(UDDl) specification. 

Once a Web service is published, a service requester 
may find the service via the UDDl interface. The UDDl 
registry provides the service requester with a WSDL 
service description and a URL (uniform resource lo¬ 
cator) pointing to the service itself. The service re¬ 
quester may then use this information to directly bind 
to the service and invoke it. 

For a more complete description of these Web ser¬ 
vices components, see the architecture document. 1 

The Web services programming stack. We now give 
a brief introduction to the Web services program¬ 
ming stack. This stack is a collection of standardized 
protocols and application programming interfaces 
(APIs) that lets individuals and applications locate 
and utilize Web services. After introducing the stack 
itself, we illustrate how each of its layers facilitates 
the use of Web services. 

Prominent at each layer in the Web services pro¬ 
gramming stack is the standardization of simple, 
open protocols and APIs. This standardization is the 
key to the ubiquitous deployment of Web services 
architectures, and the ubiquitous deployment of the 
infrastructure is the key to the network effect of Web 
services adoption. 

The network is the foundation layer for the Web ser¬ 
vices programming stack (Figure 2). All Web services 
must be available over some network. The network is 
often based on an http protocol, but other kinds of 
network protocols, such as the Internet Inter-ORB** 
Protocol (hop**) or the IBM MQSeries*, are also 
used. 2 

On top of the networking layer is an XML-based mes¬ 
saging layer that facilitates communications between 
Web services and their clients. The messaging layer 
is based on SOAP. SOAP is an xml protocol that fa¬ 
cilitates the publish, find, bind, and invoke opera¬ 
tions described previously . 3 


Figure 1 Web services actors, objects, and operations 



Figure 2 Web services programming stack 
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WSDL is a specification that describes available Web 
services to clients. These descriptions take the form 
of XML documents for the programming interface 
and location of Web services. 4 

The three layers described thus far are required in 
order to have interoperable Web services. These lay¬ 
ers also create a low-cost entry for leveraging Web 
services by allowing these services to be deployed 
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over the Internet. The remaining layers in the pro¬ 
gramming stack are optional and will be used as bus¬ 
iness needs require them. 

Publication of a service is really any action by the 
service provider that makes the WSDL document 
available to a potential service requester. Sending 
the WSDL (or a URL pointer to the WSDL) as an e-mail 
to a developer is considered to be publishing. Pub¬ 
lishing is also advertising the WSDL in a UDDI reg¬ 
istry for many developers or executing services to 
find. 5 

Likewise, discovery of a service is any action that 
gives the service requester access to the WSDL for a 
service. The action may be as simple as accessing a 
file or URL containing the WSDL or as complex as 
querying a UDDI registry and using the WSDL file(s) 
to select one of many potential services. The service 
flow layer of the stack facilitates the composition of 
Web services into workflows and the representation 
of this aggregation of Web services as a higher-level 
Web service. Standardization activity at this level is 
ongoing, but IBM has produced the Web Services 
Flow Language (wsfl) as its input to the standard¬ 
ization process. 6 

In order for a Web services application to meet the 
stringent demands of today’s e-businesses, enter¬ 
prise-class infrastructure must be supplied, includ¬ 
ing security, management, and quality-of-service 
management. These infrastructure items represented 
by the vertical towers on the right side of Figure 2 
must be addressed at each layer of the stack. The 
solutions at each layer may be independent of one 
another. More of these vertical towers will emerge 
as the Web services paradigm is adopted through¬ 
out the industry. 

We have briefly summarized the layers and standards 
in the Web services programming stack. In the next 
section, we present a scenario describing how these 
standards apply in the real world. 

Applying Web services standards to a 
business scenario 

In this section we show how Web services standards 
apply to a business situation. 

The ClearSailing Corporation and its customers. 

Consider a hypothetical corporation called ClearSail¬ 
ing that provides a set of Web services oriented 
toward facilitating parts purchasing within a partic¬ 


ular industry, let us say the sailboat manufacturing 
industry. ClearSailing has three sets of customers: 

1. Merchants who sell sailboat parts to sailboat man¬ 
ufacturers 

2. Buyers employed by sailboat manufacturers to 
procure sailboat parts 

3. Procurement managers employed by sailboat 
manufacturers to establish purchasing policies for 
their companies 

ClearSailing serves as a broker among these three 
sets of customers. Relationships among ClearSail¬ 
ing and its customers are illustrated in Figure 3. 
These relationships are indicated by the correspond¬ 
ing boxed numbers in the figure, as follows: 

1. Merchants who wish to sell sailboat parts to man¬ 
ufacturers through ClearSailing register with 
ClearSailing, describing their goods and prices. 

2. When a sailboat manufacturer wants to order 
goods through ClearSailing, its procurement man¬ 
ager sets up user profiles for each of the compa¬ 
ny’s buyers, establishing purchase areas and pur¬ 
chase limits for each user. 

3. Once each buyer’s profile has been set up, the 
buyer can access the ClearSailing registry of mer¬ 
chants. 

4. The buyer can then browse individual merchant’s 
catalogs to determine which merchants have ap¬ 
propriate parts at the best combination of price 
and quality for that buyer’s company. 

5. The buyer can place items from multiple mer¬ 
chants into a single shopping cart and then sub¬ 
mit his or her order to ClearSailing for execution. 

6. When it receives the order, ClearSailing initiates 
a business process, validating the purchase against 
the company procurement policies defined by the 
procurement manager, submitting appropriate or¬ 
ders to the individual merchants, and updating 
order status. 

7. Finally, ClearSailing reports the order status back 
to the buyer. 

Success factors for ClearSailing Corporation. In or¬ 
der to be successful with its set of Web service ap¬ 
plications, ClearSailing must devise and utilize soft¬ 
ware that meets a number of requirements. Among 
them are the following: 

• ClearSailing must be able to exchange informa¬ 
tion programmatically with its users over a net¬ 
work. 

• ClearSailing and its users must share a common 
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Figure 3 ClearSailing and its customers 



set of data and message formats for things such as 
orders and catalog information. 

• ClearSailing and its users must have a common un¬ 
derstanding of the meaning of the contents of the 
messages they exchange. For example, a buy or¬ 
der must be commonly understood by the buyers, 
the merchants, and ClearSailing itself. 

• ClearSailing must provide a mechanism to allow 
merchants to inform potential buyers that they 
have appropriate merchandise. 

• ClearSailing must provide a mechanism to allow 
potential buyers to discover available merchandise 
that meets their needs. 

• ClearSailing must have a way to combine its own 
service applications with those of its merchants in 
workflows that are appropriate for its business 
environment. 

• In order to be commercially viable, ClearSailing 
must provide its customers with a way to ensure 
that their transactions are conducted in a secure 


environment, with appropriate quality of service 
(which may include guaranteed availability levels, 
transaction support, etc.). 

How Web services standards help solve e-business 
problems. The Web services environment differs 
from previous programming environments in one re¬ 
spect only: Web services components (service appli¬ 
cations and clients) use generally accepted standard¬ 
ized APIs to communicate at each level of the pro¬ 
gramming stack. In this subsection we describe how 
the Web services standards in the Web services con¬ 
ceptual stack help solve the problems mentioned 
above. 

Networking standards for Web services. In order for 
ClearSailing to communicate with its users in an au¬ 
tomated fashion, both must either share a common 
networking protocol or use a protocol converter to 
convert between the networking protocols each uses. 
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Until relatively recently, no single networking pro¬ 
tocol has been pervasive. Such early networking pro¬ 
tocols as the IBM Systems Network Architecture 
(SNA) did not generally extend across enterprise 
boundaries, so communications over these networks 
tended to be limited to users and servers within a 
single corporation. The same is true of distributed 
remote procedure call (rpc) -based protocols such 
as HOP for CORBA** (Common Request Broker Ar¬ 
chitecture**) and the Microsoft Common Object 
Model (COM) protocol. The growth of the public net¬ 
work known as the Internet, based on Transmission 
Control Protocol/Internet Protocol (tcp/ip) and re¬ 
lated protocols such as http, has greatly extended 
the ability of companies such as ClearSailing to eas¬ 
ily and automatically communicate with its users, 
whether these users are computers or human beings. 

Although HTTP use within an enterprise is growing, 
multiple networking protocols are still often found. 
The basic communications requirement stated above 
still holds—there must either be one common pro¬ 
tocol or a protocol converter—but the growth of 
TCP/IP and HTTP has greatly facilitated communica¬ 
tions between a service provider and service request¬ 
ers, and has greatly extended the potential number 
of users available. 

In the example illustrated in Figure 3, procurement 
manager, buyers, and merchants are all communi¬ 
cating with ClearSailing services and the ClearSail¬ 
ing registry via HTTP. Within the ClearSailing Cor¬ 
poration itself, multiple networking protocols may 
be used, but in this case adapters will convert be¬ 
tween these protocols and http for messages that 
pass through the enterprise boundary to and from 
users. 

Messaging standards for Web services. The common 
network described above circulates messages among 
service providers and requesters. However, in order 
for successful communications to occur, both the ser¬ 
vice providers and the requesters must agree to a 
common format for the messages being delivered so 
that they can be properly interpreted at each end. 
An order flowing from ClearSailing to a merchant 
must have an organization or message format that 
is understood at both ends. 

Messages delivered over a network tend to fall into 
two general categories: 

1. Messages that are composed primarily of a doc¬ 
ument that is to be processed remotely 


2. Messages that contain commands and parame¬ 
ters that are used to directly invoke a remote pro¬ 
cedure (i.e., remote procedure calls) 

Until relatively recently, there was no common pro¬ 
tocol for handling both types of messages; indeed, 
multiple protocols have been used to handle mes¬ 
sages of each type. For example, products such as 
the IBM MQSeries have proprietary protocols for for¬ 
matting and delivering messages of the first type 
listed above, whereas protocols such as Remote Mes¬ 
sage Invocation (rmi) for the Java** programming 
language and the Microsoft COM protocol have been 
used to format messages of the second type. 

In the last few years, xml has gained widespread ac¬ 
ceptance as a standard specification for data markup, 
validity checking, and tagging. XML greatly aids in 
the generation, validation, and machine interpreta¬ 
tion of complex data structures or documents. 

Built on top of XML, SOAP is the standardized mech¬ 
anism for communicating document-centric mes¬ 
sages and remote procedure calls using XML. In other 
words, SOAP, a standard owned by the World Wide 
Web Consortium (W3C) (as xml protocol), accom¬ 
modates both types of messages described above. As 
such, it greatly enhances the ability of service pro¬ 
viders and users to properly interpret the messages 
they are exchanging with one another. 

In the example set forth in Figure 3, messages flow¬ 
ing between ClearSailing and its users (procurement 
managers, buyers, and merchants) flow in SOAP for¬ 
mat in XML documents. 

Service description standards for Web services. Given 
a common network for communicating and a com¬ 
mon set of conventions for formatting and interpret¬ 
ing messages, what is the next requirement to facil¬ 
itate communications between service provider and 
requester? They must have a common semantic un¬ 
derstanding of the content of these messages—of 
what they mean to accomplish in their transactions 
over the network. A potential requester must know 
what services are available from the service provider, 
what message format is required to invoke them, 
what costs are involved, etc. A merchant who wants 
to use the service provider to sell goods must be able 
to describe them in such a way that the service pro¬ 
vider can understand the descriptions and convey 
them to potential buyers. 

Standardization of service descriptions to support 
Web services is achieved via WSDL. This language 
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defines the interface required for interaction be¬ 
tween a requester and a service provider and also 
defines the location of the service provider. A ser¬ 
vice provider publishes a service by making its WSDL 
description document available to potential request¬ 
ers. This can be done in a variety of ways, but one 
standardized way is for the service provider to reg- 


The area of workflow and 

business process definition 
is an important one 

to Web services. 


ister the service with a registry and for the service 
requester to discover the service by searching the reg¬ 
istry. The specification used for the registry is the 
UDDI specification. 

In the example given above, a merchant who sells 
sails to sailboat manufacturers would describe wares 
in terms specified by ClearSailing and register them 
via a registry of preferred merchants for the sailing 
industry that might be maintained by ClearSailing 
or by an industry consortium. When a buyer for a 
sailboat manufacturer wanted to buy sails, the buyer 
would use this registry to discover and consider the 
wares of each registered seller of sails. A WSDL doc¬ 
ument would describe each merchant’s offerings at 
a basic programming-interface level. 

As Web services mature, industry groups will prob¬ 
ably standardize WSDL descriptions of the services 
that are important for them and their customers. 

Some business context descriptions for services have 
already been specified by UDDI, including categori¬ 
zation information on the type of business, geo¬ 
graphic location, and contact information. In order 
to facilitate discovery and usage of appropriate ser¬ 
vices, further standardization is needed of descrip¬ 
tive material for specific industries and across indus¬ 
tries; this work is ongoing in many industry groups. 7 

Service publication and service discovery standards 
for Web services. Service publication and service dis¬ 
covery go hand in hand. In the case of the Clear- 
Sailing Corporation, merchants must publish their 
services to the ClearSailing registry, and buyers must 
find these services by searching the registry for ap¬ 
propriate services. Obviously, for this operation to 


be successful, ClearSailing must provide standard 
APIs to its merchants and its buyers for publishing 
and finding services. 

ClearSailing could have devised its own APIs for find¬ 
ing and publishing services and then told merchants 
and buyers that they needed to use these services. 
This route may create a burden on the merchants 
and suppliers who are dealing with multiple service 
providers, because they would have to customize 
their applications to work with each different ser¬ 
vice provider. In fact it may mean that some mer¬ 
chants and buyers do not use ClearSailing’s regis¬ 
try. A standard is needed for publishing and finding 
Web services to make ClearSailing, the merchants, 
and the buyers successful. This standard is the UDDI 
standard mentioned previously, which provides stan¬ 
dard sets of APIs for publishing and finding services. 
Thus, the registry illustrated in Figure 3 is assumed 
to be a UDDI registry. 

There are two types of UDDI registry—public and 
private. Public registries are located at http://www. 
uddi.org and are maintained and synchronized by 
companies such as IBM and Microsoft. The registries 
at this URL are available, at no charge, to all users. 
Individual enterprises or industry consortiums main¬ 
tain private UDDI registries and control what service 
data are registered and who can access the data. The 
registry illustrated in Figure 3 is an example of a pri¬ 
vate UDDI registry. ClearSailing controls this regis¬ 
try to ensure that only merchants and buyers from 
companies that meet its strict standards are allowed 
to publish and discover information there. In this 
way, ClearSailing performs a quality-control oper¬ 
ation that facilitates trust among its users. 

Service flow standards for Web services. When deal¬ 
ing with Web services, it is often desirable to auto¬ 
matically compose Web services into a workflow, ag¬ 
gregating several simpler services into a higher-level 
service. In the ClearSailing example, the procure¬ 
ment manager for a particular sailboat manufacturer 
may wish to specify that when a buyer enters an or¬ 
der over a certain amount, the system must obtain 
the approval of the procurement manager before 
proceeding. Another example of a workflow trans¬ 
action is when ClearSailing fulfills an order, as de¬ 
scribed in steps 6 and 7 of the process set forth ear¬ 
lier for Figure 3. Here several Web services, some 
at ClearSailing and some at individual registered 
merchants’ locations, are composed into a workflow. 
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The area of workflow and business process defini¬ 
tion is an important one to Web services, and it is 
still under definition. IBM has put together a proposal 
for a Web services flow language that will serve as 
IBM’s input into the standards process in this area. 6 

Infrastructure services. In order to be viable for e- 
business, Web services must possess the same char¬ 
acteristics that business applications in an enterprise 
must possess—reliability, availability, manageabil¬ 
ity, security, etc. Figure 2 shows some of these char¬ 
acteristics as vertical towers that apply to each of the 
horizontal layers in the stack. A company such as 
ClearSailing will want to provide its merchants, buy¬ 
ers, and procurement managers with good security 
characteristics (for example, authentication of buy¬ 
ers), good quality-of-service characteristics (for ex¬ 
ample, processing a transaction in a reasonable time 
and being available 24 hours a day), good manage¬ 
ment characteristics for its Web services, etc. 

In traditional information processing environments, 
these requirements are typically met by middleware 
products such as the IBM WebSphere* Application 
Server and DB2* (DATABASE 2*) manager. To sup¬ 
port Web services, these products and those from 
other vendors must be extended to support Web ser¬ 
vices standards. This work has begun and continues 
to mature. For interoperable Web services running 
on platforms supplied by multiple vendors, standards 
are once again essential. 

Utility services. In order to be effective, infrastruc¬ 
ture services often require tailoring to the Web ser¬ 
vices they support. In the ClearSailing example, a 
security service would need to know security char¬ 
acteristics for the buying service and for each of its 
potential clients, for example. A management ser¬ 
vice would need to know which management policy 
applies to each Web service being managed. In gen¬ 
eral, the standards specified for each level in the Web 
services conceptual stack set forth in Figure 2 will 
need to be extended to accommodate information 
associated with infrastructure services. 

Infrastructure services are an example of utility ser¬ 
vices—services that exist to help business services 
achieve their goals. Utility services are used by bus¬ 
iness services to help them perform their business 
processes. 

In the ClearSailing example, when ClearSailing puts 
together its ordering service for buyers, it might use 
a buyer validation security service, a shopping cart 


service, a catalog display service, and similar services 
provided by other vendors, and tie these utility ser¬ 
vices in with the services it codes and provides itself 
by means of a workflow utility service. 

Conclusion 

In this paper, we have presented a scenario illustrat¬ 
ing how Web services may be applied to solve a real 
business problem, and we discussed both the ben¬ 
efits of Web services for business applications and 
the state of standards development for these services. 
Though the basic standards for Web services are now 
available, higher-level standards are still under de¬ 
velopment. Although valuable Web services are now 
being developed and deployed, widespread commer¬ 
cial exploitation of Web services across the public 
Internet awaits development and acceptance of high¬ 
er-level standards in such areas as security, reliable 
messaging, transaction support, and workflow. For¬ 
tunately, IBM and other software vendors are work¬ 
ing hard to help develop such standards and to have 
them widely accepted. 

* Trademark or registered trademark of International Business 
Machines Corporation. 

* * Trademark or registered trademark of the Object Management 
Group, Sun Microsystems, Inc., or Microsoft Corporation. 
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